Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-085

Text File | 1995-12-31 | 91KB | 2,386 lines

C.S.M.P. Digest             Tue, 21 Feb 95       Volume 3 : Issue 85

Today's Topics:

        AEGizmos users please read!
        Anyone made a PixPat?
        How is Mac programming REALLY done?
        Mac Primer (Vol 1) source available!!!
        Pascal Programmers Mailing List
        Scroll bar in dialog box
        SndDoCommand at interrupt time
        Using ProcPtrs in Pascal for PPC
        Vertical Text w-o QuickDraw GX
        [Q] Fading a PixMap?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (Jens Alfke)
Subject: AEGizmos users please read!
Date: Fri, 27 Jan 1995 19:01:12 GMT
Organization: Apple Computer, Inc.

I have some good news and some mixed news for users of AEGizmos. (AEGizmos
is a library I wrote, available on the Developer CD, that provides an
alternate API for packing/unpacking Apple Event descriptors. It's faster
and in many cases more convenient than the regular API.)

The good news: The Apple Event Manager is being rewritten for the Copland
system release and they're planning to roll in much of the functionality
from the Gizmos.

The mixed news: The data format of Apple Event compound descriptors
(lists, records, events) is changing in Copland. This will make operations
on them much more efficient (good) but will break code that uses existing
versions of the Gizmos (bad) since the Gizmos code gropes the internals of
the descriptors.

To help with the transition, I'm going to release a new version of the
Gizmos (incorporating some minor bug fixes) as a shared library. I hope to
get this out on the next developer CD, and will also see about uploading
it to Apple's FTP site.
By using the shared library, you can continue to use the AEGizmos API
while assuring future compatibility with Copland, since in Copland we can
just rev the library to use the new AEM structures and API.

The Copland team want to know who is using AEGizmos, especially in
commercial products. Please send mail to [e-mail]
and let him know which parts of the Gizmos you're using, for what type of
product. I'm sure he'd also be interested in your feedback on the Gizmos
API and how it could be merged with the Apple Event Manager. CC me too,
please!


Jens Alfke_________OpenDoc [e-mail]
                                              OpenDoc info: FTP to cil.org

         Visit Scenic Flood Control Dam No. 3.

+++++++++++++++++++++++++++

>From [e-mail] (Pai Technology)
Date: 2 Feb 1995 14:32:25 GMT
Organization: HiNet

Jens Alfke ([e-mail]) wrote:
: To help with the transition, I'm going to release a new version of the
: Gizmos (incorporating some minor bug fixes) as a shared library. I hope to
: get this out on the next developer CD, and will also see about uploading
: it to Apple's FTP site.

How about the licensing policy of this shared library?  Is the license
covered by MacOS SDK?  Do we have to pay a separate annual fee to Apple in
order to distribute this shared library with each of our products?

I think this kind of legal stuff is a bit annoying.


Hao-yang Wang
Pai Technology, Inc.
Taipei

+++++++++++++++++++++++++++

>From [e-mail] (MuttBovine)
Date: 4 Feb 1995 01:33:14 -0500
Organization: America Online, Inc. (1-800-827-6364)

>I think this kind of legal stuff is a bit annoying.

Yeah, laws suck. Let's repeal them all.

+++++++++++++++++++++++++++

>From [e-mail] (Matthias Neeracher)
Date: 06 Feb 1995 16:16:43 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]>, [e-mail] (Jens Alfke) writes:
> To help with the transition, I'm going to release a new version of the
> Gizmos (incorporating some minor bug fixes) as a shared library.

This is all wonderful for the PowerPC, but which shared library format do you
intend to use on 68K Macs? If it's ASLM, then AEDisposeDesc(AEGizmos) for
me. If it's CFM-68K, it will at least be a major inconvenience.

Hmmm... Copland *will* appear on both PowerPC and 68K Macs, will it? :-)

Please don't take this as a criticism of your fine work on AEGizmos.

Matthias

- ---
Matthias Neeracher <[e-mail]> http://err.ethz.ch/members/neeri.html
   "I'm set free to find a new illusion" -- Velvet Underground

---------------------------

>From [e-mail] (Chris DeSalvo)
Subject: Anyone made a PixPat?
Date: Tue, 24 Jan 1995 09:30:50 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

I've been trying desperately to do one of two things:

        Locate a utility that can convert a PICT to a 'ppat' resource
        with 256x256 dimensions and a custom color table,

                or

        Write the damn thing myself.  Tried this approach:
                Load the PICT, draw it into a GWorld.
                Call NewPixPat
                Call CopyPixMap from the GWorld's portPixMap to the
                        PixPat's patMap

        Nothing returns an error but when I go to do a FillCRect with
        my new PixPat I get garbage.

IM:Imaging with Quickdraw just sort of breezes over the fact that you
can make a PixPat but never actually explains how.

Any help appreciated,
Thanx,
Chris
--
+-----------------------------------------------------------------+
| [e-mail]           |   Macintosh:  Changing the world, |
| Chris De Salvo              |        one person at a time!      |
| Professional Mac Geek       |    -----------------------------  |
| for MacPlay, Inc.           |      (I wish they'd hurry up!)    |
+-----------------------------------------------------------------+

Any opinions expressed, or implied, are my own!  They should not be
considered representative of the opinions or policies of my employer,
MacPlay, a division of Interplay Productions, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Tue, 24 Jan 1995 16:34:10 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Chris DeSalvo ([e-mail]) wrote:
: I've been trying desperately to do one of two things:

:       Locate a utility that can convert a PICT to a 'ppat' resource
:       with 256x256 dimensions and a custom color table,

I think DeskTextures does 256 square patterns.

:               or

:       Write the damn thing myself.  Tried this approach:
:               Load the PICT, draw it into a GWorld.
:               Call NewPixPat
:               Call CopyPixMap from the GWorld's portPixMap to the
:                       PixPat's patMap

Maybe the author would clue you as to how he did it.

-Ken-

+++++++++++++++++++++++++++

>From [e-mail] (Chris DeSalvo)
Date: Wed, 25 Jan 1995 08:54:04 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Ok, I figured out how to do it.  The following is a BinHex'd
CodeWarrior 5 .c file of my final function.  It takes a PICT resource
and moves all of the pixel data and the color table of the PICT into a
new PixPatHandle.  I had to read the section in IM:Quickdraw about a
dozen times to figure it out.  You get it for free...


-- end

L8R
Chris
--
+-----------------------------------------------------------------+
| [e-mail]           |   Macintosh:  Changing the world, |
| Chris De Salvo              |        one person at a time!      |
| Professional Mac Geek       |    -----------------------------  |
| for MacPlay, Inc.           |      (I wish they'd hurry up!)    |
+-----------------------------------------------------------------+

Any opinions expressed, or implied, are my own!  They should not be
considered representative of the opinions or policies of my employer,
MacPlay, a division of Interplay Productions, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Ivan M CaveroBelaunde)
Date: Wed, 25 Jan 1995 15:10:46 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Chris DeSalvo) writes:
>I've been trying desperately to do one of two things:

>       Locate a utility that can convert a PICT to a 'ppat' resource
>       with 256x256 dimensions and a custom color table,

>               or

>       Write the damn thing myself.  Tried this approach:
>               Load the PICT, draw it into a GWorld.
>               Call NewPixPat
>               Call CopyPixMap from the GWorld's portPixMap to the
>                       PixPat's patMap

>       Nothing returns an error but when I go to do a FillCRect with
>       my new PixPat I get garbage.

I'm not sure if this is the problem (I wasn't using the code in question
to create PixPats, and I believe there's something special about PixPat
organization in memory, such as bit packing and some of the flags in
the pixpat struct), but doing CopyPixMap from GWorlds is potentially
problematic: GWorld pixmaps are "special": their pmVersion field can contain
formally undocumented values, which denote whether the pixmap's baseaddress
is a handle or a pointer to a locked handle. The pmVersion then changes
value whenever you change the locked state of the gworlds's pixels; normally
the pmVersion is (I think) 2, denoting a handle for baseAddr, and when you
call LockPixels the handle gets locked, the dereffed handle gets stuffed
into the baseAddr, and pmVersion changes to 1, denoting a locked pixmap.

You might want to look into the snippets on the developer CDs, I seem to
remember a "pixmap to pixpat to ppat" snippet on it.

HTH,

-Ivan
- -
Ivan Cavero Belaunde ([e-mail], [e-mail])
Avid VideoShop Lead
Avid Technology, Inc.





+++++++++++++++++++++++++++

>From [e-mail] (Jens Alfke)
Date: Thu, 26 Jan 1995 18:34:28 GMT
Organization: Apple Computer, Inc.

> [e-mail] (Chris DeSalvo) writes:
> >I've been trying desperately to do one of two things:
>
> >       Locate a utility that can convert a PICT to a 'ppat' resource
> >       with 256x256 dimensions and a custom color table,
>
> >               or
>
> >       Write the damn thing myself.  Tried this approach:
> >               Load the PICT, draw it into a GWorld.
> >               Call NewPixPat
> >               Call CopyPixMap from the GWorld's portPixMap to the
> >                       PixPat's patMap
>
> >       Nothing returns an error but when I go to do a FillCRect with
> >       my new PixPat I get garbage.

1. You need to set up the PixPat's pixel storage first -- resize it, lock
it down, point the baseAddr in the PixMap to it -- before you do the
copyBits.
2. Remember to call PixPatChanged (or is that ChangedPixPat?) afterwards.
3. Did you set up the PixPat's color table first?


Jens Alfke_________OpenDoc [e-mail]
                                              OpenDoc info: FTP to cil.org

         Visit Scenic Flood Control Dam No. 3.

+++++++++++++++++++++++++++

>From [e-mail] (Roy Lovejoy)
Date: Sun, 5 Feb 1995 07:47:36 GMT
Organization: Adept Solutions

One thing that I found, when I did *MY* desktop pattern editor, (three
years BEFORE Wall Paper, I might point out :), is that the PixPat's
storage has to be exact, i.e. 256 x 256 at 8 bit needs to have 65536
bytes. If you are of the anal type programmer, you might have already
noticed that you get bonus bytes in your (**pixmaphandle).rowBytes, that
belong to GWorlds, EVEN IF YOU ARE AT A POWER OF TWO. So in the 256 x 256
8 bit case, you might see 260 for your row bytes.

I had to dupe the GWorlds's baseAddr to get a handle I could shrink, then
Munger() the (rowBytes-width) off of each line. *THAT* data could then be
used in a ppat.
- -------------------------------------------------------------------
Roy Lovejoy          PHONE: [phone]  INET:[e-mail]
Pixel PooBah           FAX: [phone]   ALINK: ............. adept
Adept Solutions      PTALK                   CIS: ........ 72447,1447
524 Avenida Verde       DD: 619.598.5225  eWorld: ........ adeptsolns
San Marcos CA 92069                          AOL: ........ adeptsolns
- -------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Sun, 05 Feb 1995 10:14:05 +0100
Organization: The Conspiracy

In article <[e-mail]>,
[e-mail] (Jens Alfke) wrote:

>> >               Load the PICT, draw it into a GWorld.

Did you lock the GWorld before drawing into it or copying out
of it?

Cheers,

                                                        / h+


--
  Jon Wdtte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

"If you want to see a pipelined execution model, go to a laundromat."
     Richard Clark


---------------------------

>From [e-mail] (William Wake)
Subject: How is Mac programming REALLY done?
Date: 30 Jan 1995 16:05:11 GMT
Organization: Virginia Tech, Blacksburg, Virginia

I've just come "back" to trying to program the Mac, and have worked my way
through Sydow's _Macintosh Programming Techniques_. (I liked this book, by the
way.)

I appreciate the resource-based approach the Mac uses, but some of the
techniques in the book just don't seem like they'd scale up, so I'm curious
what you really do.

+ Resources are mapped to the program by a bunch of #define's. This seems like
it would get out of hand in a program with a realistic set of resources.

+ The book's approach to event handling is to take each event and decode where
it will go. This is trivial when you only have a window or two, but not so
maintainable when there are many.

+ Things like writing in color or black-and-white are sprinkled all over the
code. ("if (color_system) {do-it-one-way} else {do-it-another}")

+ Do real apps use TCL or PowerPlant? Do those tools handle much of the
event-to-object mapping? (I'm used to NeXT's Interface Builder, where that's
done in a more integrated way than what I've seen on the Mac.)

Now, I realize an intro book is lucky to introduce the basics in a satisfactory
way, much less address issues of scaling up and maintaining large programs.

So, what do you REALLY do?

        Bill Wake
        Virginia Tech

+++++++++++++++++++++++++++

>From [e-mail] (ALTURA)
Date: 31 Jan 1995 04:47:31 -0500
Organization: America Online, Inc. (1-800-827-6364)

> + Resources are mapped to the program by a bunch of #define's. This
seems like
> it would get out of hand in a program with a realistic set of resources.

That's how I do it.  Although, I now think enums are a better choice.

> The book's approach to event handling is to take each event and decode
where
> it will go. This is trivial when you only have a window or two, but not
so
> maintainable when there are many.

Some sort of general event handling scheme is better in this case.  I
usually associate some generalized handlers (i.e. for click, update, etc.)
with every window and then let the window's handler decide what to do.

> Things like writing in color or black-and-white are sprinkled all over
the
> code. ("if (color_system) {do-it-one-way} else {do-it-another}")

I do it this way as well.  However, in future large projects I'll probably
generalize drawing with some sort of device driver metaphor so that I
don't have to do all that if'ing.

> Do real apps use TCL or PowerPlant? Do those tools handle much of the
> event-to-object mapping? (I'm used to NeXT's Interface Builder, where
that's
> done in a more integrated way than what I've seen on the Mac.)

I've never used a third-part framework.

I'm curious about others' experiences.

-Jordan

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 31 Jan 1995 11:27:03 GMT
Organization: Ecole Normale Superieure, PARIS, France

In article <3gj2nn$[e-mail]>,
William Wake <[e-mail]> wrote:

>+ Resources are mapped to the program by a bunch of #define's. This seems like
>it would get out of hand in a program with a realistic set of resources.
You're right. I only write medium-sized programs and yet my resource
management is quite messy. I have to be very careful to check that my
#define's and my resources don't get out of sync. I wish the development
environment would do something about it (are you listening, MetroWerks?)


--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/index.html ...

+++++++++++++++++++++++++++

>From [e-mail] (David Phillip Oster)
Date: Tue, 31 Jan 1995 12:48:24 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <3gl6q7$[e-mail]> [e-mail] (Francois Pottier) writes:
_>In article <3gj2nn$[e-mail]>,
_>William Wake <[e-mail]> wrote:

_>>+ Resources are mapped to the program by a bunch of #define's. This seems like
_>>it would get out of hand in a program with a realistic set of resources.

_>You're right. I only write medium-sized programs and yet my resource
_>management is quite messy. I have to be very careful to check that my
_>#define's and my resources don't get out of sync. I wish the development
_>environment would do something about it (are you listening, MetroWerks?)

There is a trick to it:
1.) define your resources in the Rez language (as supported by MPW, THINK C,
        and ToolServer==MPW)
2.) write a file called, say Rez.h, that only contains #defines,
for example:
/* MENU resources
 */
#define kAppleMenu              128
#define kFileMenu               kAppleMenu+1
#define kEditMenu               kFileMenu+1

then include it in both your .c files and your .r files.
Similarly, including comments for each item in your DITLs and STR#s that
gives the enum by which that item is known in C is a good way to avoid
getting out of sync.
--
- ------- [e-mail] ----------
There is no sight finer than that of the planet Earth in your rearview mirror.



+++++++++++++++++++++++++++

>From [e-mail] (Alex Curylo)
Date: 31 Jan 1995 19:53:22 GMT
Organization: First Ascent

In article <3gl6q7$[e-mail]>
[e-mail] (Francois Pottier) writes:

> You're right. I only write medium-sized programs and yet my resource
> management is quite messy. I have to be very careful to check that my
> #define's and my resources don't get out of sync.

What most people I know do is use common Rez and program headers,
usually with a .r.h or .common.h (as in AppsToGo) suffix. That makes it
easy enough
that I really haven't noticed this as being a problem.

If it makes you feel any better, Windows programs don't seem to have
any more elegant way to deal with this, at least not the ones I port.

Alex Curylo  [e-mail]  [phone], fax -1359
***  First Ascent: Mac programming, UP paragliders, indie CDs  ***

+++++++++++++++++++++++++++

>From [e-mail] (Sardaukar)
Date: 31 Jan 1995 21:25:15 -0500
Organization: America Online, Inc. (1-800-827-6364)

1) Resource management is just experience.  A large program will typically
have a lot of resources, of both standard and custom types.  All you have
to do is bull your way through a big project once, and you'll come up with
a way that works good for you.

2) Event handling is much the same.  It's very very easy to just switch
down through event types and through the various windows and such. Don't
get too hung up on one person's technique for this.  Some people have
structs for each window with proc ptrs to the event handlers, some have a
massive switch statement.  Do whatever is easiest for you and your
asociates to *read* and *follow*.

3) Things like color/b&w, stereo/mono, 1 bit/8/bit/16/bit/24bit, gray
palette/system pallette, scsi4.3/old scsi... etc.  Handling all of these
issues is the responsibility of the product designer. Your product is
obliged to handle the current operating environment in the most
Macintosh-friendly way. The Macintosh makes it ridiculously easy to
determine what features are available, what state the System is in, etc.
Then you take the appropriate action.  That's a big difference between the
Macintosh and that other piece-of-crap industry.

examples:
- your program should display and draw in a manner appropriate for the
pixel depth of the monitor your windows are on
- your program should enable/disable controls as appropriate for what
features are available.
- your program should determine at startup what major features are
required to operate and quit gracefully if the current operating
enviroment is inadequate.
- your program should never make assumptions about the contents of the
System or a particular mac model but should test for specific features.

All of this kind of stuff is all over Inside Macintosh.  I suggest you
look at Apple's sample code for examples as well

4) Some people *do* use frameworks - some don't.  In many instances a
framework is inappropriate.  Also, some frameworks suck.  You have to be
careful in selecting one.  A beginner should always code things "by hand".
 Then ater a couple of major projects you can move to a framework if you
find one you like (PowerPlant is pretty good).  However, the game is
changing rapidly.  With the advent of OpenDoc, the small developer will
gain an advantage by using the OpenDoc development framework.  For now
just write code.

+++++++++++++++++++++++++++

>From [e-mail] (William Edward Woody)
Date: Wed, 01 Feb 1995 13:00:08 -0800
Organization: In Phase Consulting

In article <3gj2nn$[e-mail]>, [e-mail] (William
Wake) wrote:

> I've just come "back" to trying to program the Mac, and have worked my way
> through Sydow's _Macintosh Programming Techniques_. (I liked this book,
by the
> way.)
>
> I appreciate the resource-based approach the Mac uses, but some of the
> techniques in the book just don't seem like they'd scale up, so I'm curious
> what you really do.
>
> + Resources are mapped to the program by a bunch of #define's. This
seems like
> it would get out of hand in a program with a realistic set of resources.

Actually the resource-based approach scales nicely. I tend to isolate the
accessor functions which access a particular resource into a single function
(for those resources which the Macintosh OS doesn't provide an accessor
function for me), and I wind up putting all of the #define's into a
single 'resource.h' file. A typical 'resource.h' file for a typical
program winds up being several hundreds of lines. On the other hand,
you can group those '#defines' into groups; all of the cursors go after
the /* CURSORS */ comment, all of the menus go after the /* MENUS */, etc.

> + The book's approach to event handling is to take each event and decode
where
> it will go. This is trivial when you only have a window or two, but not so
> maintainable when there are many.

I personally do two things.

(1) I use the 'windowKind' field in the WindowRecord to determine the
general class of window I'm dealing with (floating window, drawing window,
etc.)

(2) I put a pointer to my application's data structures (in this case,
the pointer to my TWindow record) into the window's refCon field.

My inner event loop looks almost exactly like the code in the book, except
that my individual event handler routines (DoUpdate, DoActivate) gets
the TWindow record which contains my data, looks up the windowKind field,
and switches to the correct DoUpdateXXX routine depending on the
contents of the windowKind field.

> + Things like writing in color or black-and-white are sprinkled all over the
> code. ("if (color_system) {do-it-one-way} else {do-it-another}")

Yep, it's really done this way. The best way to do it is to write it as
if you are in a black and white system, except mark those things that
I would like in color with a /* ###C */ comment. Then I add color by
doing a global search for '###C', and add in the color code I wanted to
add, using the if statement you've got above.

> + Do real apps use TCL or PowerPlant? Do those tools handle much of the
> event-to-object mapping? (I'm used to NeXT's Interface Builder, where that's
> done in a more integrated way than what I've seen on the Mac.)

I don't, but a lot of people do. I *do* use an application interface
class; one that I wrote myself.

These things *do* do all of the event to object mapping for you; that
is their biggest strength.

For example, if you have a window class called TWindow, with a method
called 'DoUpdate' in C++, your DoUpdate routine looks like:

        DoUpdate(WindowPtr w)
        {
            TWindow *tw;

            // map window record to window pointer
            tw = GetTWindow(w);

            // Do the update process, calling the window class's drawing code
            BeginUpdate(w);
            SetPort(w);

            tw->DoUpdate();

            EndUpdate(w);
        }


> Now, I realize an intro book is lucky to introduce the basics in a
satisfactory
> way, much less address issues of scaling up and maintaining large programs.
>
> So, what do you REALLY do?

The most important thing to do is to have a programming style and convention
which makes your source code consistant across modules. This allows you
to maintain *any* large program without getting confused.

What I do is use the following:

ALL functions begin with a comment of the format:

        /*  function_name
         *
         *       Description of function_name goes here. Enough
         *  information is placed here to figure out what the function
         *  does without ever having to actually look at the code.
         */

I use a mixed-case style of naming functions. For example, 'FunctionName'.
However, this can be confused with Apple's naming convention, and using
'_'-deliminated function names may make sense, for example, 'function_name'.

Variables local to a scope (local to a structure, local to a class,
local to a function) all start with a lower-case charager; ie, 'localPoint'.

Variables global in scope start with an upper-case 'G' character; ie,
'GMyPoint', 'GGlobalPoint'. (Even though 'Global' begins with an upper-case
'G', the separate upper-case 'G' is required, as the G in Global is part
of Global. No fair being tricky; it's only you who you are fooling.)

Constants begin with a capital 'K'; 'KMaxLines'.

Variables which are static scoped (which survive across function invocations
or are static in classes) begin with a lower-case 'g'; ie, 'gWindowList'.

Classes begin with a capital 'T'; mix-in classes begin with a 'M'. (Mixin
classes are classes which are never expected to be used to create an
object, but only add functionality to an existing class hierarchy. For
example, I have a mix-in class which provides 'undo' functionality to
an editor which uses linked-list objects. It's a mix-in class, because
from 'undo' functionality one does not create an object.)

And so forth.


This may seem stupid, but when you are starting to write programs with
around 100,000 lines of code in the main application, having a constant
way of writing your code helps a great deal in keeping track of all of
the information.

Remember, the only difference between a big program and a small program
is that a big program is a lot larger, and thus harder to keep in your
brain all at once. Having a constant programming style allows you to
in a sense 'swap' code out of your brain and onto the page, without making
the process of 'swapping' the code back in difficult.

Ever try to go back and read old code that you wrote two or three years
ago? It's like reading the code of a stranger, unless you have a
constant style.

                                                        - Bill

--
William Edward Woody     |  e-mail: [e-mail]
In Phase Consulting      |  WWW:    http://alumni.caltech.edu/~woody
337 West California #4   |  Fax:    [phone]
Glendale, CA 91203       |  ICBM:   N:34.4' W:118.15'

+++++++++++++++++++++++++++

>From [e-mail] (William Wake)
Date: 1 Feb 1995 15:23:44 GMT
Organization: Virginia Tech, Blacksburg, Virginia

In article <3gmreb$[e-mail]> [e-mail] (Sardaukar)
writes:
> 3) Things like color/b&w....
> Handling all of these issues is the responsibility
> of the product designer.

My question was not so much WHETHER to handle them as HOW to handle them. I was
curious if people really write their code like this:
        if (system_is_color) {
                do it the color way
        } else {
                do it the b/w way
        }

Or rather, do they set up "intermediaries" in a sort of OO way, perhaps setting
up pointers to functions or building up a generic "screen_manager" type object
that does its own tracking of screen depth.

What I'm getting at is that I haven't seen a lot of Mac code, but  a lot of
what I've seen hasn't been all that great-looking from a maintenance point of
view.

        Bill Wake
        [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Denis Birnie)
Date: Thu, 02 Feb 1995 11:11:09 +1200
Organization: Information Services, University of Canterbury

>My question was not so much WHETHER to handle them as HOW to handle them. I was
>curious if people really write their code like this:
>
>        if (system_is_color) {
>                do it the color way
>        } else {
>                do it the b/w way
>        }
>
>Or rather, do they set up "intermediaries" in a sort of OO way, perhaps setting
>up pointers to functions or building up a generic "screen_manager" type object
>that does its own tracking of screen depth.
>
At some point you have to have code like that above, whether it's...
 * high-up and called just once to determine which functions to call later
 * low-down in the actual draw-stuff code (library routines)
 * or springled all through the code
...is up to you (of course the third option wouldn't be terribly smart)

I take option 2 in order to keep as much of the code as common as
possible.  For example to draw the background (pattern) in a window I
might do this...

  FancyBackground();
  DrawBitOfBackGround(&theBit);
  PlainBackground();

Where FancyBackground is defined like...

void FancyBackground( void )
{
   if (OffWorldIsColour) ForeColor(greenColor);
   if (FancyBackgroundPat != NIL) {
      HLock((Handle) FancyBackgroundPat);
      BackPixPat(FancyBackgroundPat);
   };
}

This handles three cases...
 * B/W   - just draw a gray pattern
 * <4bit - just draw a gray pattern, but in green
 * 4+bit - use a colour pattern (PPAT)

This works for me - it's perhaps not optimal but it does go.

Denis
--
The above in no way reflects the opinion or standards of...
 - the University of Canterbury
 - the doctors who give me my medication
 - myself, five minutes from now, then, tomorrow or yesterday...
                              (depending on your timezone :-)
- --

+++++++++++++++++++++++++++

>From [e-mail] (Sardaukar)
Date: 1 Feb 1995 23:45:44 -0500
Organization: America Online, Inc. (1-800-827-6364)

what you do for drawing in ports is use DeviceLoop().  See "Inside
Macintosh: Imaging with QuickDraw" for more.

+++++++++++++++++++++++++++

>From [e-mail] (Sardaukar)
Date: 1 Feb 1995 23:50:12 -0500
Organization: America Online, Inc. (1-800-827-6364)

Look, kids, listen to this William Woody guy.  He's got it *right on the
money*.  If I still had a company I'd offer him a job. Although I'd needle
him about the "_" underscores.

'Nuff said.


+++++++++++++++++++++++++++

>From [e-mail] (Ingemar Ragnemalm)
Date: 2 Feb 1995 09:12:48 GMT
Organization: (none)

[e-mail] (ALTURA) writes:

>> + Resources are mapped to the program by a bunch of #define's. This
>seems like
>> it would get out of hand in a program with a realistic set of resources.

>That's how I do it.  Although, I now think enums are a better choice.

Big deal - anything that defines constants, so we can write kGeneralAlert
instead of 128. #define, enum, Pascal's const (which I use), what's the
difference?

>> The book's approach to event handling is to take each event and decode
>where
>> it will go. This is trivial when you only have a window or two, but not
>so
>> maintainable when there are many.

>Some sort of general event handling scheme is better in this case.  I
>usually associate some generalized handlers (i.e. for click, update, etc.)
>with every window and then let the window's handler decide what to do.

I use TransSkel. For small programs, I use a plug-in event loop that goes
between the main program and a set of application-dependent event handlers.
The event loop itself should not be cluttered with application-dependent
tasks.

>> Things like writing in color or black-and-white are sprinkled all over
>the
>> code. ("if (color_system) {do-it-one-way} else {do-it-another}")

>I do it this way as well.  However, in future large projects I'll probably
>generalize drawing with some sort of device driver metaphor so that I
>don't have to do all that if'ing.

I write glue code for the more common cases, PlotCIcon, for example (which
definitely lets itself be implemented in a non-color version).

--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 2 Feb 1995 11:07:47 GMT
Organization: Ecole Normale Superieure, PARIS, France

In article <woody-0102951300080001@192.0.2.1>,
William Edward Woody <[e-mail]> wrote:

>function for me), and I wind up putting all of the #define's into a
>single 'resource.h' file. A typical 'resource.h' file for a typical
>program winds up being several hundreds of lines.

That's what I did do, but it's a pain because adding a single resource
means recompiling all files that use resources, that is almost the whole
project (10 minutes on my IIci).

On the other hand, if each file has its own resource definitions, resource
ID conflicts are hard to avoid. It looks like it's a problem without a good
solution. The good solution would be a dedicated tool to sync code and
resources, I think.

--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
Check my WWW page at http://acacia.ens.fr:8080/home/pottier/index.html ...

+++++++++++++++++++++++++++

>From [e-mail] (David Casseres)
Date: Thu, 02 Feb 1995 10:23:14 -0800
Organization: Apple Computer, Inc.

In article <3gq7mg$[e-mail]>, [e-mail] (Ingemar
Ragnemalm) wrote:

> [e-mail] (ALTURA) writes:
>
> >> + Resources are mapped to the program by a bunch of #define's. This
> >seems like
> >> it would get out of hand in a program with a realistic set of resources.
>
> >That's how I do it.  Although, I now think enums are a better choice.
>
> Big deal - anything that defines constants, so we can write kGeneralAlert
> instead of 128. #define, enum, Pascal's const (which I use), what's the
> difference?

#define is not part of the language, properly speaking, and it only does a
mindless lexical substitution.  That means that the meaning of
"KGeneralAlert" might be different in different contexts, and you might
not find the rules spelled out in a language standard.  The trend in C++,
at least, is to get away from using preprocessor directives for anything
that can be done with the compiler, which is presumably smarter and whose
behavior is more standardized.

const is a standard language feature but it carries too much baggage; it
isn't what we are used to thinking of as a constant, rather it is a
full-blown variable that the compiler allows you to initialize but not to
assign to after initialization.  Personally I find this lame.

enum is also a standard language feature but it means the same as a
traditional integer constant.  It's what I use, though I think it's lame
to have to use the enum syntax when all you want is integer constants.

It's important to be consistent, and since almost all constants are either
integers, or characters, or strings, I use enums everywhere.

And BTW don't let me get started on how C treats character and string
constants!  The great thing about C++ (besides the fact that it exists) is
that it's just C.  And the awful thing about C++ (besides the fact that
we're gonna be stuck with it forever) is that it's just C.

--
David Casseres
Exclaimer: Hey!

+++++++++++++++++++++++++++

>From [e-mail] (Stefan Kurth)
Date: Wed, 01 Feb 1995 17:59:38 +0100
Organization: none

Alex Curylo <[e-mail]> wrote:

> What most people I know do is use common Rez and program headers, usually
> with a .r.h or .common.h (as in AppsToGo) suffix. That makes it easy
> enough that I really haven't noticed this as being a problem.

You mean you have -all- your resources in rez format?  Icons and PICTs
and all?

________________________________________________________________________
Stefan Kurth               Berlin, Germany           [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Thu, 02 Feb 1995 14:34:55 -0700
Organization: cellular

In article <3gqee3$[e-mail]>,
[e-mail] (Francois Pottier) wrote:

> On the other hand, if each (source) file has its own resource definitions,
> resource ID conflicts are hard to avoid. It looks like it's a problem
> without a good solution. The good solution would be a dedicated tool to
> sync code and resources, I think.

If you have an IDE which allows you to put multiple resource files into a
project (THINK Project Manager, CodeWarrior) *and* tells you about
resource ID conflicts when it's building the final target (THINK Project
Manager), then you can associate resource files with source files quite
freely.

Of course, it would be better to have a more seamless tool.

______________________________________________________________________________
 Pete Gontier -- MacZealotry, Ink. -- [e-mail]

 "It's great to work for a company that lets you build good software
  and doesn't give you any shit..."
             -- John McEnerney, Metrowerks PowerPC Product Architect

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Thu, 02 Feb 1995 14:42:26 -0700
Organization: cellular

In article <3gq7mg$[e-mail]>,
[e-mail] (Ingemar Ragnemalm) wrote:

> #define, enum, Pascal's const (which I use), what's the difference?

Among things posted by others, an 'enum' lets you define a series of
values without naming each value in the series:

        enum
        {
                kResID_Dialog_TooLow = 127,
                kResID_Dialog_YesNoCancel,
                kResID_Dialog_SimpleMessage,
                kResID_Dialog_Configuration
        };

If you want to add a member to this list, there's no need to bump the
values of each member up or down. In fact, there's no need to assign each
symbol a value in the first place. This is less useful for resource IDs,
of course, than it is for many other purposes. For example, 'STR#'
indexes.

Of course, in Pascal, you (may) have to devise something else, since enums
are not (fully, if at all) scalar.

______________________________________________________________________________
 Pete Gontier -- MacZealotry, Ink. -- [e-mail]

 "It's great to work for a company that lets you build good software
  and doesn't give you any shit..."
             -- John McEnerney, Metrowerks PowerPC Product Architect

+++++++++++++++++++++++++++

>From [e-mail] (David Phillip Oster)
Date: Thu, 2 Feb 1995 23:45:21 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <3goems$[e-mail]> [e-mail] (Stefan Kurth) writes:
>You mean you have -all- your resources in rez format?  Icons and PICTs
>and all?

Yes and no. Anything that can't be usefully described textually (i.e.,
will just be meaningless strings of hex at best) you handle with the
line in your .r file:

include "pictorial.resources";

which copies all the resources in that file into the output of the .r
--
- ------- [e-mail] ----------
There is no sight finer than that of the planet Earth in your rearview mirror.



+++++++++++++++++++++++++++

>From [e-mail] (ALTURA)
Date: 2 Feb 1995 19:45:26 -0500
Organization: America Online, Inc. (1-800-827-6364)

> Big deal - anything that defines constants, so we can write
kGeneralAlert
> instead of 128. #define, enum, Pascal's const (which I use), what's the
> difference?

#defines can be bad because they don't follow scoping rules.  This
generally isn't a problem (especially if you make them all UPPERCASE), but
enums are safer.  Also, enums have the advantage of auto-incrementing.
So, for menus I can do:

enum {
   file_menu = 100,
      open_command = 1,
      close_command,
      . . .
};

Further, most compilers (other than ThinkC) can't display #defines
symbollically - which is very annoying.

* * *

Another message mentioned putting all the resource #defines/enums in one
header.  I really like this approach because it makes it very easy to see
which IDs have been used and the appropriate next ID to use.

-Jordan

+++++++++++++++++++++++++++

>From [e-mail] (Alex Curylo)
Date: 3 Feb 1995 07:23:55 GMT
Organization: First Ascent

In article <[e-mail]>
[e-mail] (David Phillip Oster) writes:

> Yes and no. Anything that can't be usefully described textually (i.e.,
> will just be meaningless strings of hex at best) you handle with the
> line in your .r file:
>
> include "pictorial.resources";

Unless, of course, you're using Code Warrior for the project, in which
case you include the .rsrc files of your choice directly into the
project file. (Now if they would just include autorezzing .r files...
:)

Alex Curylo  [e-mail]  [phone], fax -1359
***  First Ascent: Mac programming, UP paragliders, indie CDs  ***

+++++++++++++++++++++++++++

>From [e-mail] (Majjick)
Date: 3 Feb 1995 21:35:20 -0500
Organization: America Online, Inc. (1-800-827-6364)

Can I be the only person to wish that there was a PL/I compiler for the
Mac?  What it is to be alone in the Universe...

Paul Magnussen

+++++++++++++++++++++++++++

>From [e-mail] (Mike White)
Date: 6 Feb 1995 23:35:50 GMT
Organization: University of Massachusetts, Amherst

Ingemar Ragnemalm ([e-mail]) wrote:

: Big deal - anything that defines constants, so we can write kGeneralAlert
: instead of 128. #define, enum, Pascal's const (which I use), what's the
: difference?

Enums are a better way to represent abstraction than #defines.  While they
essentially do the same job, enums can embody things conceptually so
that code will make sense to you or someone else later.  For example:

enum {Sun, Mon, Tue, Wed, Thu, Fri, Sat}

is clearly better than

#define Sun 1;
#define Mon 2;
etc..

This is true also for resources as you can enum resources which are
related and mutually exclusive.
--
***************************************************************************
*  Michael White                *  "Man is a biped without feathers."     *
*  [e-mail]  *                                 -Plato  *
***************************************************************************

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Tue, 7 Feb 1995 16:34:13 +1300 (NZDT)
Organization: (none)

[e-mail] (Majjick) writes:
> Can I be the only person to wish that there was a PL/I compiler for the
> Mac?  What it is to be alone in the Universe...

Why would you want PL/I when you can have languages with features
piled on like Ada and C++?? :-)


-- Bruce
   who on his first job in 1984 was given the choice of buying one of a
   FORTRAN, COBOL or PL/1 compiler.  Wheeee!!  What choice!!

   (I took PL/I, of course)

---------------------------

>From [e-mail] (DMark)
Subject: Mac Primer (Vol 1) source available!!!
Date: 7 Feb 1995 19:22:31 -0500
Organization: America Online, Inc. (1-800-827-6364)

Well, I finally got everything together and uploaded to an FTP site that
accepts anonymous FTPs. The site name is:

ftp.u.washington.edu

and the folder to look in is:

/pub/user-supported/DaveMark/Primer1

There are four files in the directory. One has the Primer source in
CodeWarrior format, one has the Primer source in THINK C format, one has
the actual apps in 68K format and the last has the actual apps in PowerMac
format.

Feel free to download the files and upload them to your own bboards, FTP
sites, whatever. Oh, yeah, there's also a copy of THIN C 2.0 at the same
site in the folder:

/pub/user-supported/DaveMark/LearnC

Thanks for your patience and please help me spread the word...

Dave Mark

---------------------------

>From [e-mail] (Peter N Lewis)
Subject: Pascal Programmers Mailing List
Date: Thu, 02 Feb 1995 16:56:59 +0800
Organization: Curtin University

I expect I'll regret this.  I've set up a mailing list for Pascal
programmers.  This list is for discussions that particularly relate to
programming the Macintosh in Pascal (MPW, MW, THINK, LS, whatever),
including problems related to SOM, ASLM, Universal Interfaces, PPC/68k,
UniversalProcPtr, etc etc.  This is *not* for general programming Q&A
(which belongs on one of the comp.sys.mac.* newsgroups).  People from
companies that produce Pascal compilers are welcome and encouraged to join
the list.

The main reason for providing this list is to avoid creating a newsgroup,
since I think most Pascal questions are really generic programming
questions and should be asked on the normal newsgroups.  Only discussions
particularly relating to Pascal should be on this list.  However, that
said, there are a lot of topics of concern to Pascal programers
(especially the problems of dealing with all the new technologies), and
hopefully this list will be a useful tool for discussing solutions to
these new problems.

To subscribe, send mail to [e-mail], any subject and body

subscribe pascal Your Name

(eg "subscribe pascal Peter N Lewis")

Enjoy,
   Peter.
--
The probability of me making it to the WWDC in 1995 is currently: 74%

+++++++++++++++++++++++++++

>From [e-mail] (Bill the Cat)
Date: Fri, 03 Feb 1995 15:50:51 -0800
Organization: Larryville

In article <[e-mail]>,
[e-mail] (Peter N Lewis) wrote:

> I expect I'll regret this.  I've set up a mailing list for Pascal
> programmers.  This list is for discussions that particularly relate to
> programming the Macintosh in Pascal (MPW, MW, THINK, LS, whatever),
> including problems related to SOM, ASLM, Universal Interfaces, PPC/68k,
> UniversalProcPtr, etc etc.  This is *not* for general programming Q&A
> (which belongs on one of the comp.sys.mac.* newsgroups).  People from
> companies that produce Pascal compilers are welcome and encouraged to join
> the list.
>
> The main reason for providing this list is to avoid creating a newsgroup,
> since I think most Pascal questions are really generic programming
> questions and should be asked on the normal newsgroups.  Only discussions
> particularly relating to Pascal should be on this list.  However, that
> said, there are a lot of topics of concern to Pascal programers
> (especially the problems of dealing with all the new technologies), and
> hopefully this list will be a useful tool for discussing solutions to
> these new problems.
>
> To subscribe, send mail to [e-mail], any subject and body
>
> subscribe pascal Your Name
>
> (eg "subscribe pascal Peter N Lewis")
>
> Enjoy,
>    Peter.


I think this is a great idea.  I've already got a list of many MAC
programmers interested in a Pascal group.  I can E-mail you that list, or
simply add you to mine (or both).

Regards,
Bill

---------------------------

>From [e-mail]
Subject: Scroll bar in dialog box
Date: 4 Feb 1995 18:40:32 -0600
Organization: UTexas Mail-to-News Gateway

        What can I say?  After almost a month struglling with the bloody
thing, I still cannot get a simple scroll bar to work with my dialog
box.  This is getting aggravating, you know. =(

The idea here is to pop up a modal dialog box that would allow the user
to set up some stuff in my program (isn't that what dialogs are for?).
The main routine (Think C 5.0 code BTW) is the following:

#include "KitCat.h"

/*********************************************************************
 *
 * Routine to handle the gSetup dialog:
 *      o Initialize the dialog
 *      o Pop it up
 *      o Check whether the user has pressed the OK button
 *      o Dispose of the dialog, freeing all Heap storage associated with
 *        the dialog
 *
 *********************************************************************/
void DoSetupDialog()
{
        int                             itemHit, dialogDone = FALSE;
        int                             itemType;
        Rect                    itemRect;
        Handle                  itemHandle;
        GrafPtr                 oldPort;
        DialogPtr               gSetup;

        gSetup = GetNewDialog(SETUP, NIL_POINTER,
                                   MOVE_TO_FRONT); /* Initialize Dialog */

        if ( gSetup == NIL_POINTER)
                return;

        ShowWindow ( gSetup );       /* Popup the dialog                */

    GetPort ( &oldPort );        /* Save the old top window         */
    SetPort ( gSetup );          /* Set gSetup to be the top window */

    GetDItem( gSetup, setupOkButton, &itemType, &itemHandle,
                  &itemRect);        /* Get handle (itemHandle) for     *
                                      * setupOkButton                   */
        OutlineButton( (ControlHandle) itemHandle);
                                     /* Put double pixel border around  *
                                      * setupOkButton                   */

        while ( dialogDone == FALSE )
        {
                ModalDialog ( NIL_POINTER, &itemHit);
                switch(itemHit)
                {
                        case setupOkButton:
                                dialogDone = TRUE;
                                break;

                        case setupCancelButton:
                                dialogDone = TRUE;
                                break;

                        case setupVolumeControl:
                                DoControlVolume(gTheEvent.where, gSetup);
                                break;

                }
        }

        DisposDialog (gSetup);    /* Dispose of the dialog   */
    SetPort ( oldPort );           /* Restore the old top window    */
}

As you probably have noticed, my tabs that looked so nice in Think C 5
look terrible here.  Bear with me.  The routine that is supposed to play
with the scroll bar, DoControlVolume, is shown below:

#include "KitCat.h"

/*********************************************************************
 *
 * Routine to handle the gSetup dialog:
 *      o Initialize the dialog
 *      o Pop it up
 *      o Check whether the user has pressed the OK button
 *      o Dispose of the dialog, freeing all Heap storage associated with
 *        the dialog
 *
 *      NOTE
 *
 *      o DialogPtr = WindowPtr = GrafPtr
 *
 *********************************************************************/
void DoControlVolume( Point thePoint, GrafPtr theWindow)
{
        int                             itemHit;
        int                             itemType;
        Rect                    scrollBarRect;
        Handle                  itemHandle;
        GrafPtr                 oldPort;
        ControlHandle   scrollBarHandle, theControl;
        short int               thePart;

    SetPort ( theWindow );     /* Set theWindow to be the top window */

        GetDItem( theWindow, setupVolumeControl, &itemType, &scrollBarHandle,
                          &scrollBarRect);

        GlobalToLocal(&thePoint);
        thePart = FindControl(thePoint, theWindow, &theControl);

        if(theControl == scrollBarHandle)
        {
                if(thePart == inThumb)
                {
                        thePart = TrackControl( theControl, thePoint,
                        NIL_ACTION_PROC);
                }
                else
                {
                        thePart = TrackControl( theControl, thePoint,
                        &DoScroll);
                }
        }
}

The routine I am using to handle the bloody scroll bar is pretty much
taken from the Macintosh C Programming Primer:

#include "KitCat.h"

/*********************************************************************
 *
 * Function to handle a scroll bar, updating it.
 *
 *********************************************************************/
pascal void DoScroll(ControlHandle theControl, int theCode)
{

        int curControlValue, maxControlValue, minControlValue;

        maxControlValue = GetCtlMax(theControl);
        minControlValue = GetCtlMin(theControl);
        curControlValue = GetCtlValue(theControl);

        switch(theCode)
        {
                case inPageDown:
                case inDownButton:
                        if (curControlValue < maxControlValue)
                                curControlValue +=1;
                        break;
                case inPageUp:
                case inUpButton:
                        if (curControlValue > minControlValue)
                                curControlValue -=1;
                        break;
        }
        SetCtlValue(theControl, curControlValue);

}

The scroll bar itself is defined as a control and installed in the dialog
using ResEdit.  I did that since I though I could then use GetDItem to
get the Handle to it.  Am I right?  Anyway, what do I get off the above
piece of code?  Nothing.  No action from the scroll bar.  As in previous
questions, suggestions are more than welcome.

+++++++++++++++++++++++++++

>From [e-mail] (Roy Lovejoy)
Date: Sun, 5 Feb 1995 08:02:20 GMT
Organization: Adept Solutions

In article <[e-mail]>,
[e-mail] wrote:

>         What can I say?  After almost a month struglling with the bloody
> thing, I still cannot get a simple scroll bar to work with my dialog
> box.  This is getting aggravating, you know. =(
>

What you are running into is the fact that the Dialog Manager calls
TrackControl() {for better or worse}, for you. (That's what makes the
buttons/checkboxes/radio buttons track so nicely.) The problem is that YOU
get control too late, if you WAIT until after ModalDialog().

What I have found to work quite nicely (in a number of commercial sw
packages), is to just have pass an event proc to ModalDialog(), and in
*THAT* proc, check to see if the event is a mouse down in your control (by
using FindControl() in the event proc.) You can compare control handles,
refcons, or my favorite, titles, to see if the click is on a scroll bar
(which you should handle) or something else (which is best left to
ModalDialog(). (I name ALL of my scroll bars "slider", that never shows up
anywhere, so I can use one routine to handle such an instance).

So the main point is YOU need to grab the event before ModalDialog() does.
Where? In the event proc. If it is YOUR event, and YOU call TrackControl()
be sure to 'erase' the event in your ModalDialog event filter by stuffing
a 0x00 into the event.what field (so ModalDialog() will ignore it).

But a bigger issue is your skating close to one of the original (yes, that
means 1984) ten commandments. Thou shalt not use the Dialog Manager for
your complicated UI. Scroll bars (other than the ListManager's) might
indicate a level of complexity that should be addressed by going straight
for the groin & using the Window Manager, controls & event loops. Although
the solution I gave above will work 100%, You now are delving into many
more callback & hooks & this proc & that proc, than is humanly necessary.
If you did this manually with Window Manager & your own Control Handles,
etc, the only hook you would need is the TrackControl one (which you would
need anyhow.)

there.
- -------------------------------------------------------------------
Roy Lovejoy          PHONE: [phone]  INET:[e-mail]
Pixel PooBah           FAX: [phone]   ALINK: ............. adept
Adept Solutions      PTALK                   CIS: ........ 72447,1447
524 Avenida Verde       DD: 619.598.5225  eWorld: ........ adeptsolns
San Marcos CA 92069                          AOL: ........ adeptsolns
- -------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 5 Feb 1995 14:16:56 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>,
[e-mail] wrote:

<         What can I say?  After almost a month struglling with the bloody
< thing, I still cannot get a simple scroll bar to work with my dialog
< box.  This is getting aggravating, you know. =(
<
< The idea here is to pop up a modal dialog box that would allow the user
< to set up some stuff in my program (isn't that what dialogs are for?).
< The main routine (Think C 5.0 code BTW) is the following:
<
< /*********************************************************************
<  *
<  * Routine to handle the gSetup dialog:
<  *      o Initialize the dialog
<  *      o Pop it up
<  *      o Check whether the user has pressed the OK button
<  *      o Dispose of the dialog, freeing all Heap storage associated with
<  *        the dialog
<  *
<  *      NOTE
<  *
<  *      o DialogPtr = WindowPtr = GrafPtr
<  *
<  *********************************************************************/
< void DoControlVolume( Point thePoint, GrafPtr theWindow)
< {
<         int                             itemHit;
<         int                             itemType;
<         Rect                    scrollBarRect;
<         Handle                  itemHandle;
<         GrafPtr                 oldPort;
<         ControlHandle   scrollBarHandle, theControl;
<         short int               thePart;
<
<     SetPort ( theWindow );     /* Set theWindow to be the top window */
<
<         GetDItem( theWindow, setupVolumeControl, &itemType, &scrollBarHandle,
<                           &scrollBarRect);
<
<         GlobalToLocal(&thePoint);
<         thePart = FindControl(thePoint, theWindow, &theControl);
<
<         if(theControl == scrollBarHandle)
<         {
<                 if(thePart == inThumb)
<                 {
<                         thePart = TrackControl( theControl, thePoint,
<                         NIL_ACTION_PROC);
<                 }
<                 else
<                 {
<                         thePart = TrackControl( theControl, thePoint,
<                         &DoScroll);
<                 }
<         }
< }
<
< The routine I am using to handle the bloody scroll bar is pretty much
< taken from the Macintosh C Programming Primer:
<
<
< The scroll bar itself is defined as a control and installed in the dialog
< using ResEdit.  I did that since I though I could then use GetDItem to
< get the Handle to it.  Am I right?  Anyway, what do I get off the above
< piece of code?  Nothing.  No action from the scroll bar.  As in previous
< questions, suggestions are more than welcome.

I don't think that you need all this code for calling TrackControl.
ModalDialog will do this for you.  All you want is to call GetControlValue
when the user hits the OK button.

Is your CNTL for your scrollbar marked 'enabled'?  There is a bug in
ResEdit regarding the item rects for CNTLs.  Open up the CNTL and open up
the DITL with the 'Open as template' menu item.  Verify that the item
rects are the same.  Often they are not and the dialog manager ignores the
hits because the item rects are out of sync.

You should really be using a slider for setting a volume, not a scroll
bar.  There are a handful of slider CDEFs at the various archives.  The
one that I like is by Harold Ekstrom and is at the alt.sources.mac
archive.

You are skating on very thin ice by using ints when dealing with the
toolbox.  In your 'DoControlVolume' routine you pass the address of an int
to GetDItem.  This is very bad.  The toolbox expects the address of shorts
in this call.  If you have 4 byte ints turned on you will be screwed.
When dealing with the toolbox it is a good idea to always explicitly use
long ints or short ints.  If you are passing an address to the toolbox you
must use a long or a short.  Having code that depends on the size of an
int will get you in trouble sooner or later.

Good luck,

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

---------------------------

>From "Andrew C. Plotkin" <[e-mail]>
Subject: SndDoCommand at interrupt time
Date: Tue, 31 Jan 1995 11:57:05 -0500
Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA

(And lo, I have been enlightened as to GWorlds, so it's on to the next thing:)

Anyone know which SndCommands can safely be sent to the Sound Manager at
interrupt time? NIM:Sound charmingly comments that "most" can, and you
can do the rest by "preconfiguring the channel with a soundCmd at
non-interrupt time." Uh, great. Nowhere (that I can find) does it say
which commands are unsafe, although I *think* it's implying that
soundCmd is not.

It's the "draft" version of NIM:Sound that I have, off the Develop 19
bookmark CD; maybe the version on the NIM collection CD has more info?

--Z (This user may move or allocate memory, so he should not be emailed
at interrupt time)

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From [e-mail] (In The Dark Water)
Date: 4 Feb 1995 20:15:42 GMT
Organization: Vnet Internet Access, Charlotte, NC -  [e-mail]

Andrew C. Plotkin ([e-mail]) wrote:
: (And lo, I have been enlightened as to GWorlds, so it's on to the next thing:)

Indeed, have a cold one, buddy.  GWorlds deserve a little post-brain
activity.:)

: Anyone know which SndCommands can safely be sent to the Sound Manager at
: interrupt time? NIM:Sound charmingly comments that "most" can, and you
: can do the rest by "preconfiguring the channel with a soundCmd at
: non-interrupt time." Uh, great. Nowhere (that I can find) does it say
: which commands are unsafe, although I *think* it's implying that
: soundCmd is not.

It is safe to call SndDoCommand() and SndDoImmediate at the interrupt
level, as long as you keep the standard interrupt level coding rules in
mind.  Specifically, remember that interrupt routines cannot access a
low memory global, especially with a ToolBox call.  They cannot access
unlocked handles or other relocatable memory objects.  Memory Manager
cannot allocate or alter a handle's state, or dispose of objects.  Most
importantly, when you call an interrupt routine on a 68K machine, A5
globals are no longer pointed to by A5.

Taking all this into account (Mac programming can really be fun
sometimes, eh?), you should be able to use freqCmd, freqDurationCmd,
um..callBackCmd, and everything else.  HOWEVER, you may not be able to
use soundCmd or bufferCmd.  These commands may allocate memory, if you've
prepared a sound channel in one format and want to play a sound in
another format in it, or if you play a new sound that is compressed.

All the above is much more clearly explained in the most excellent book,
"Ultimate Mac Programming", by Dave Mark, IDG Books 1994.  This book has
an entire chapter devoted to Sound Manager, along with tons of info on
Apple Events, OSA, the Object Model, patching traps, and generally all
the other cool stuff you want to know about.  The book comes with a CD
which contains tons of code and utilities, as well as a working copy of
CodeWarrior.  IMHO, if you're doing Mac programming, you need this book.
Anyway, I hope this info helps (most of it's paraphrased from the book);
if you want to get into it more, definitely get the final IM:Sound.  If
you'd like, drop me some email sometime.  Chances are, I've lost some
hair and/or brain cells over it, and there's no reason anybody else
should be unnecessarily bald :)

Thanks,

Brian Neal
Dogcowboy
[e-mail]

Apple Computer: The Power To Be Your Best.
Microsoft:      The Power To Tell You What Your Best Will Be.



---------------------------

>From [e-mail] (Jim Wintermyre)
Subject: Using ProcPtrs in Pascal for PPC
Date: Mon, 30 Jan 1995 23:30:00 GMT
Organization: Rome Laboratory

I often use procPtrs to make my code more flexible.  For example, in a
generic modal dialog routine I have, one of the parameters is a procPtr
to a routine that gets called in my ModalDialog loop, like so:

  repeat
   ModalDialog(@MyFilter, item);

   if modalCallBack <> nil then
    begin
     GetPort(oldPort);
     SetPort(theDialog);

{$IFC UNDEFINED Application}
     SetupA4;
{$ENDC}

     MCallBack(theDialog, item, modalCallBack); { call callback routine
}

{$IFC UNDEFINED Application}
     RestoreA4;
{$ENDC}

     SetPort(oldPort);
    end;

  until item in [kOKItem, kCancelItem];


To call this routine, which is declared as:

  procedure ModalCallBack (theDialog: DialogPtr; item:integer);

I use the following inline code:

  procedure MCallBack (theDialog: DialogPtr; item: integer;
                       theRoutine: ProcPtr);
   inline
    $205F,      { movea.l (sp)+,a0 }
    $4E90;      { jsr (a0) }


Now I'm converting the above code to work with CodeWarrior, and I'd
like to set it up so that it will compile for  68K or PPC.  My question
is, how do I get this to work in PPC code?  I assume I would have to
use PPC inline assembly?  The callback routine is in the same project
as the above code, so I know that it is going to be PPC code if the
above is PPC code; thus I don't believe I have to worry about using
UPPs.

Any ideas?

Thanks,
Jim

[e-mail]
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Wed, 01 Feb 1995 10:52:15 +0800
Organization: Department of Computer Science, University of Western Australia

In article <[e-mail]>,
[e-mail] (Jim Wintermyre) wrote:

>Now I'm converting the above code to work with CodeWarrior, and I'd
>like to set it up so that it will compile for  68K or PPC.  My question
>is, how do I get this to work in PPC code?  I assume I would have to
>use PPC inline assembly?  The callback routine is in the same project
>as the above code, so I know that it is going to be PPC code if the
>above is PPC code; thus I don't believe I have to worry about using
>UPPs.

You need to read up about procedural types, a new extension to Pascal by
the Metrowerks people (praise be to Marcel!) that allows you to do this
sort of thing cleanly, without resorting to inlines.  It's all there in
the documentation.

The procedure type extensions remind me very much of Modula 2.  In fact
lots of MW Pascal reminds me of Modula 2, including procedure types,
qualified identifiers, system units, and so on.  Which is cool because
Modula 2 is IMHO the best simple procedural language every developed.

Share and Enjoy.
--
Quinn "The Eskimo!"     "Ah, so that's the secret,
                         if only Captain Bipto had known."

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Fri, 03 Feb 1995 10:27:54 +0800
Organization: Curtin University

>Well, something like that. Pretty neat, but what bothers me is that I know no
>way to assign and identify a "no function" value (i.e. nil) for a function
>valiable. I can use pointers to function variables, but @MyFunction is NOT
>a pointer to a function variable, and won't work.

I'd suggest reporting this as a bug.  I'm not sure if we reported it as a
bug when we were testing out procedure types, but we did come to the same
conslusion.

Every data type should have a "null" value.  For example, what is a null
valud for file reference numbers?  I normally use bad_rn = -32768, but
it'd be nice if the system defined one.  The alternative is using an rn
and a boolean, and that gets quite painful very quickly.

Enjoy,
   Peter.
--
The probability of me making it to the WWDC in 1995 is currently: 75%

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Sun, 05 Feb 1995 10:14:15 +0100
Organization: The Conspiracy

In article <[e-mail]>,
[e-mail] (Peter N Lewis) wrote:

>Every data type should have a "null" value.  For example, what is a null
>valud for file reference numbers?  I normally use bad_rn = -32768, but
>it'd be nice if the system defined one.  The alternative is using an rn
>and a boolean, and that gets quite painful very quickly.

0 is a good null value for files; it's always allocated to the
system resource file, and since you shouldn't be messing with
that, safely assume 0 == NULL frefnum.

Cheers,

                                        / h+


--
  Jon Wdtte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

"If you want to see a pipelined execution model, go to a laundromat."
     Richard Clark


---------------------------

>From [e-mail] (Michael Peirce)
Subject: Vertical Text w-o QuickDraw GX
Date: Sat, 18 Feb 95 20:17:28 PT
Organization: Peirce Software, Inc.

Someone was asking about how to do vertical text.

While I agree that QuickDraw GX makes this trivial, I also realize
most people haven't switch over to it yet.  So I dug this postig out
of my archives.  Reposted w/o permission, sorry Martin...

_______
From: [e-mail] (Martin Minow)
Subject: Re: Vertical Text in QuickDraw
Date: 27 Jun 92 02:21:27 GMT


[e-mail] asks about drawing text vertically. When I
had this problem, I solved it by writing the text into an offscreen
grafport, and transposing the port. Here's the subroutine for your
reading pleasure:

/*
 * Transpose an arbitrary bitmap (i.e., rotate it 90!).
 */

#ifdef DOCUMENTATION

Title           Transpose a Bitmap

Usage

                #include "Support.h"

                GrafPtr
                TransposeGrafPort(srcPort)
                GrafPtr                 srcPort

                Return a GrafPort whose bitmap that is the transpose of
                the source bitmap (i.e., what was vertical in the source
                becomes horizontal in the destination).  This routine calls
                routines in the OffscreenGrafPort library to create the
                new port.

                If the source bitmap is invalid (or there is no memory),
                TransposeGrafPort returns NIL (zero).

                The result is rotated 90! counter-clockwise.  I.e., the
                upper-left pixel in the source becomes the lower-left
                pixel in the destination:

                        ****                     **  ***
                        *       *                       *   *
                        ****    becomes *   *
                        *       *                       *   *
                        *       *                       ********


Normal Usage:

                        GrafPtr                 savePort;
                        GrafPtr                 srcPort;
                        GrafPtr                 dstPort;

                        GetPort(&savePort);
                        srcPort = CreateOSGrafPort(rect);
                        ... drawing commands ...
                        dstPort = TransposeGrafPort(srcPort);
                        SetPort(savePort);
                        DeleteOSGrafPort(srcPort);
                        if (dstPort != NIL) {
                                CopyBits(
                                        &dstPort->portBits,
                                        &window->portBits,
                                        &dstPort->portBits.bounds,
                                        &drawing_rect,
                                        srcCopy,
                                        NIL
                                );
                                DeleteOSGrafPort(dstport);
                        }

author

                Martin Minow.

Copyright

                Copyright 1989, Martin Minow.  All rights reserved.

                You may redistribute or incorporate this software in
                any application without restriction as long as this
                copyright notice remains intact and this source is not
                redistributed for profit.

#endif

#include "Support.h"

/*
 * This macro returns a pointer to the byte containing [v, h]
 *              base            is src_base or dst_base
 *              rowBytes        is src_rowBytes or dst_rowBytes
 *              v                       is the vertical coordinate
 *              h                       is the horizontal coordinate
 */
#define loc(base, rowBytes, v, h)               \
        (unsigned char *) ((base) + ((long) (v) * (rowBytes)) + ((h) >> 3))

GrafPtr
TransposeGrafPort(srcPort)
GrafPtr                         srcPort;
{
                register short                  i;
                register short                  j;
                register short                  k;
                register unsigned char  *ptr;
                GrafPtr                                 dstPort;
                BitMap                                  *src;
                BitMap                                  *dst;
                Rect                                    dst_rect;
                int                                             dst_width, dst_height;
                int                                             src_max;
                Ptr                                             src_base;
                Ptr                                             dst_base;
                short                                   src_rowBytes, dst_rowBytes;

                /*
                 * Get the destination bitmap organization (transposed)
                 * and create the destination bitmap..
                 */
                src = &srcPort->portBits;
                dst_rect.top    = src->bounds.left;
                dst_rect.left   = src->bounds.top;
                dst_rect.bottom = src->bounds.right;
                dst_rect.right  = src->bounds.bottom;
                if ((dstPort = CreateOSGrafPort(dst_rect)) == NIL)
                        return (NIL);
                EraseRect(&dst_rect);
                dst = &dstPort->portBits;
                src_base = src->baseAddr;
                dst_base = dst->baseAddr;
                src_rowBytes = src->rowBytes;
                dst_rowBytes = dst->rowBytes;
                dst_width = width(dst->bounds);
                dst_height = height(dst->bounds);
                k = width(src->bounds);                                 /* For mirror transform */
                for (j = 0; j < dst_height; j++) {              /* dst v, src h                 */
                        --k;                                                            /* Horiz pixel in src   */
                        for (i = 0; i < dst_width; i++) {       /* dst h, src v                 */
                                ptr = loc(src_base, src_rowBytes, i, k);
                                if ((((*ptr) >> (7 - (k & 7))) & 1) != 0) {
                                        ptr = loc(dst_base, dst_rowBytes, j, i);
                                        *ptr |= (0x80 >> (i & 0x7));
                                }
                        }
                }
                return (dstPort);
}

- -
 Note: the above should have tabs set every 4 bytes.
Also note that it presupposes a subroutine that creates an offscreen
GrafPort to hold the destination rect.

Martin Minow
[e-mail]

__ Michael Peirce        __ [e-mail]
__ Peirce Software, Inc. __ 719 Hibiscus Place, Suite 301
__                       __ San Jose, California USA 95117-1844
__ Makers of: SMOOTHIE & __ voice: +1.408.244.6554 fax: [phone]
__    PEIRCE PRINT TOOLS __ AppleLink & AOL: peirce

---------------------------

>From [e-mail] (Aris Zakinthinos)
Subject: [Q] Fading a PixMap?
Date: 30 Jan 95 15:18:08 GMT
Organization: Computer Science Research Institute

In an application I am working on I have a slide show.  I fade the screen
to black then fade it back with the first picture.  What I think would be
really cool is if the picture faded out and the next picture faded in.  I
don't want to fade the whole screen because there is writting on the
screen.  I thought the best way would be to have the picture have its own
GDevice then fade the GDevice the same way I fade the screen.  But I am
not sure this will work or even how to do it.  Any help would be
appreciated.

Thanks in advance.

Aris.

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Mon, 30 Jan 1995 20:15:56 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Aris Zakinthinos ([e-mail]) wrote:
: In an application I am working on I have a slide show.  I fade the screen
: to black then fade it back with the first picture.  What I think would be
: really cool is if the picture faded out and the next picture faded in.  I
: don't want to fade the whole screen because there is writting on the
: screen.  I thought the best way would be to have the picture have its own
: GDevice then fade the GDevice the same way I fade the screen.  But I am
: not sure this will work or even how to do it.  Any help would be
: appreciated.

Here's a routine from Mac Shonle (BendImageFast, PaletteTricks,
clutFader1.2) used in a picture to picture fade.  The fade, in his demo,
uses the whole screen.  He has a palette for the first picture and one
for the second and this routine fades between the palettes.  But, you
should be able to make it applicable to only a portion of the screen
(i.e: a window or rect).

Mac is going to release free demo source for this, once finalized.

void FadeToPalette( long numTicks,
                        CTabHandle destTab,
                            GDHandle aGDevice )
{
    // get the monitorUs current clut
    CTabHandle    srcTab = (**(**aGDevice).gdPMap).pmTable;

    // We want the range for each color to be of an
    //  unsigned short, but we need negative numbers,
    //  so these signed longs are the solution.
    long        redDelta[256];
    long        greenDelta[256];
    long        blueDelta[256];

    // used to clear up clutter in the code
    long        difference;

    long        i;             // used to cycle trough loops
    long        colorIndex;    // used to cycle through color indices

    long        theTicks;

    // to help us return stuff the way we found it
    GDHandle    oldGDevice;

    // we will only do it on 8-bit devices
    if( (**(**aGDevice).gdPMap).pixelSize != 8 )
        return;

    oldGDevice = GetGDevice();    // save the old

    SetGDevice( aGDevice );       // set it to the monitor to be faded

    /**** Set up the deltas ****/
    for( colorIndex=0; colorIndex<256; colorIndex++ )
    {
        /* This is what I am thinking: take the difference between
        the two colors and divide it by the number of steps
        (numTicks). So we will have a number that can be subtracted
        to the source numTicks times and have it end up equaling
        the destination.
        */

        difference = ( (long)(**srcTab).ctTable[colorIndex].rgb.red -
                       (long)(**destTab).ctTable[colorIndex].rgb.red );
        redDelta[colorIndex] = difference / numTicks;

        difference = ( (long)(**srcTab).ctTable[colorIndex].rgb.green -
                       (long)(**destTab).ctTable[colorIndex].rgb.green );
        greenDelta[colorIndex] = difference / numTicks;

        difference = ( (long)(**srcTab).ctTable[colorIndex].rgb.blue -
                       (long)(**destTab).ctTable[colorIndex].rgb.blue );
        blueDelta[colorIndex] = difference / numTicks;
    }

    /**** Do the fade ****/
    for( i=0; i<numTicks; i++ )
    {    theTicks = TickCount() + 1;            // one tick

        for( colorIndex=0; colorIndex<256; colorIndex++ )
        {    // make the source more and more like the dest
            (**srcTab).ctTable[colorIndex].rgb.red -=
                      redDelta[colorIndex];
            (**srcTab).ctTable[colorIndex].rgb.green -=
                    greenDelta[colorIndex];
            (**srcTab).ctTable[colorIndex].rgb.blue -=
                     blueDelta[colorIndex];
        }

        SetEntries( 0, 255, (ColorSpec *)&(**srcTab).ctTable );

        // wait until the one tick is done
        while( theTicks > TickCount() )
            ;
    }

    // set it to the dest, just in case
    SetEntries( 0, 255, (ColorSpec *)&(**destTab).ctTable );
    MakeITable( nil, nil, 0 );

    SetGDevice( oldGDevice );    // return it back to itUs old state
}

Obviously, unix doesn't know what the apostrophe character Mac used was.

-Ken-

+++++++++++++++++++++++++++

>From [e-mail] (Ivan Cavero Belaznde)
Date: 2 Feb 1995 15:22:50 GMT
Organization: Avid Technology, Inc.

In article <[e-mail]>,
[e-mail] (Aris Zakinthinos) wrote:

> In an application I am working on I have a slide show.  I fade the screen
> to black then fade it back with the first picture.  What I think would be
> really cool is if the picture faded out and the next picture faded in.  I
> don't want to fade the whole screen because there is writting on the
> screen.  I thought the best way would be to have the picture have its own
> GDevice then fade the GDevice the same way I fade the screen.  But I am
> not sure this will work or even how to do it.  Any help would be
> appreciated.

You cannot do that (have the picture have its own gdevice). I'd advise you
to fade the entire screen using the gamma-fading code available on various
places (Apple Dev CDs, alt.source.mac archive, etc). If you insist you
don't want to do that, then the alternative is to continuously use
CopyBits with blendMode instead of srcCopy and the opcolor set to the
blend percentage (red=green=blue=0xffff is opaque, red=green=blue=0x0000
is transparent). Do note that either you'll have to do the mix operation
onto an offscreen and then blit, or use progressive mixing (do, say, eight
passes in your loop with the blend mode set to a nonlinear values - the
first pass mixes in 1/8th, the second 1/7th, the third 1/6th, etc). The
second approach might cause objectionalble banding depending on the
contents of your image (because you're quantizing the new image to some
percentage of its original level and doing repeated mixing of it).

HTH,

-Ivan
- ---
Ivan Cavero Belaznde ([e-mail], [e-mail])
Avid VideoShop Project Lead
Avid Technology, Inc.
Disclaimer: These opinions are MINE! ALL MINE! MINEMINEMINE! HAHAHA!

+++++++++++++++++++++++++++

>From [e-mail] (Christopher Todd)
Date: 4 Feb 1995 01:29:45 GMT
Organization: Northwest Nexus Inc.


> In article <[e-mail]>,
> [e-mail] (Aris Zakinthinos) wrote:
>
> > In an application I am working on I have a slide show.  I fade the screen
> > to black then fade it back with the first picture.  What I think would be
> > really cool is if the picture faded out and the next picture faded in.  I
> > don't want to fade the whole screen because there is writting on the
> > screen.  I thought the best way would be to have the picture have its own
> > GDevice then fade the GDevice the same way I fade the screen.  But I am
> > not sure this will work or even how to do it.  Any help would be
> > appreciated.
>
> You cannot do that (have the picture have its own gdevice). I'd advise you
> to fade the entire screen using the gamma-fading code available on various
> places (Apple Dev CDs, alt.source.mac archive, etc).

Actully, I'm not sure if the gamma fade stuff is the same as the things I
have, but, the source I've got fades the pallette, using setentry and what
not...what I would do, is take a color entry in the pallete, and use that
for the text or what ever color (like if you're drawing in white on a
black background, and then fade the rest of the pallette, excluding the
color you using to display....
   or if there are a bunch of things you want to use, assign like 16 or
pallette entries, and make sure the pictures don't have those colors in
them, then fade all the colors that aren't those 16 or so... that way,
only the things with the colors you want to fade will fade, and the others
will stay bright and clear....

--
[e-mail]         \   /-         | \
                           \ /           |
                             |            \
                             \             |
                              \_         _/      Tora

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Sat, 4 Feb 1995 18:27:58 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

I've seen about boxes where only part of the box is faded in and out,
with the desktop colors surrounding the dialog remaining intact, as well
as the rest of the dialog.

Metrowerks C about bow fades in scrolling text which fades in as it rises
(credits).  So the idea that the whole screen needs done is in error.

I believe the trick is to use the system colors, and never use any R, G,
or B values other than those.  In other words, use only 4096 steps and
nothing in between.

256 divided by 4096 is 16.  So if the red and/or green and/or blue is
incremented or decremented by 4096, then there are 16 levels for each hue.

If a picture is in a rect, the pixels are of various values.  If you want
to fade that rect to black, why couldn't you decrement the RGB values of
all the pixels 4096 at a time to 0?

If it's 65535, 0, 0 then dropping the 65535 to 61439, 57343, 53247, etc,
would fade the red to black.

Conversely, if the rect is now black, and you wanted to fade in a picure,
you'd need to find the values of the pictures RGB and "morph" it in by
only increasing the RGB for that rect by appropriate amounts until an
equalization occurred.

It's like a progress bar.  The total change needed gets calculated, then
change begins, then progress of change is reported until "changed" equals
"total change".

Maybe RGB value could be incremented or decremented during a refresh - I
don't know.

In a color paint program, if you fill a blue area with a blue that's 4096
darker, aen't you "fading" that portion of the pict toward black, using
the System palette, and without doing the whole screen?

Some creative hacking could do it for a portion of a windows content.
It's not that it "can't be done" - it has been done.  I've seen it in action.

making the code necessary to do it freely available?  That's what hasn't
been done (although it could be done).

-Ken-

+++++++++++++++++++++++++++

>From [e-mail] (Alan Walkington)
Date: Tue, 07 Feb 1995 17:46:09 -0700
Organization: HyperK a Division of Scientech, Inc.

In article <[e-mail]>, [e-mail] (Ken Long) wrote:

> I've seen about boxes where only part of the box is faded in and out,
> with the desktop colors surrounding the dialog remaining intact, as well
> as the rest of the dialog.
>
> Metrowerks C about box fades in scrolling text which fades in as it rises
> (credits).  So the idea that the whole screen needs done is in error.

< comments deleted >

The CW about box code is on the distribution CD ...
Maybe we can see how they did it?

--
Alan Walkington
[e-mail]

---------------------------

End of C.S.M.P. Digest
**********************



Attachment converted: Spiff:Pict2PPat.c (TEXT/MMCC) (000159F8)